So basically there are 3 ways to output list:

1. as Model
2. as Vec (should it perhaps be SharedVector instead?)
3. as Slice.

btw, where is Vec used? Is it for future use?

So IMHO, we should either have Expression::Model, Expression::Vector, Expression::Slice. Or have Expression::Array{ output: ArrayOutput, ... } with enum ArrayOutput { Model, Vector, Slice}. (Edit: output instead of the current is_model)

But IMHO, this duality with the bool is_model doesn't seem so intuitive.
Don't you think?

(I think my intuition tell me that an ArrayOutput enum is better than 3 variant of Expression because they are handled the same in many cases.)

So basically there are 3 ways to output list:

1. as Model

2. as `Vec`   (should it perhaps be `SharedVector` instead?)

3. as Slice.

btw, where is Vec used? Is it for future use?

Yes. For my work on repeating Rows, I think I need grid_layout_input_for_repeated() to return a Vec<sp::GridLayoutInputData> instead of a single sp::GridLayoutInputData.

I have yet to confirm that this is the way to go, but I thought support for returning Vecs might be useful at some point either way.

In generated code, Slice is for input values, and Vec is for return values. I don't think this needs SharedVector.
Properties are Models which are shared vectors.

So IMHO, we should either have Expression::Model, Expression::Vector, Expression::Slice.

I agree, this would be even more readable.

Or have Expression::Array{ output: ArrayOutput, ... } with enum ArrayOutput { Model, Vector, Slice}. (Edit: output instead of the current is_model)

Ah, interesting idea. I'll try that.

But IMHO, this duality with the bool is_model doesn't seem so intuitive. Don't you think?

I agree. I always found it surprising.

(I think my intuition tell me that an ArrayOutput enum is better than 3 variant of Expression because they are handled the same in many cases.)

I'll give it a try.

Yes. For my work on repeating Rows, I think I need grid_layout_input_for_repeated() to return a Vecsp::GridLayoutInputData instead of a single sp::GridLayoutInputData.

I have yet to confirm that this is the way to go, but I thought support for returning Vecs might be useful at some point either way.

This PR looks good. But i'm thinking we should wait a bit before merging to be sure this is really needed by the work on the repeated Row.

@ogoffart I confirm that this is needed for repeated Row support (which is now working, I'm doing the last bit of polishing).
Do you want to merge this or should I discard it and include it in the PR for repeated rows?
(I guess it depends on whether you review commit-by-commit or everything-at-once using "Files Changed")